Amendments to the Specification : 

Please replace the first full paragraph on page 4 as follows: 
However, there may be situations where the AS does not know whether it should 
start originating or terminating services when it receives an incoming request 
message, e.g. an SIP INVITE message, or a serving CSCF (S-CSCF) does not 
know whether the incoming request message starts an originating or terminating 
session/transaction. Moreover, other information may be needed for load balancing 
within the network. Furthermore, for load sharing purposes in a connection 
processing server (CPS), especially in the S-CSCF and an interrogating CSCF (I- 
CSCF), it is important to provide a fast and easy algorithm to discover whether a 
received SIP request is the first in a SIP session or to which SIP session a received 
request or response belongs to. Currently, SIP does not provide such an efficient 
means. In order to identify a SIP dialog, i.e. call leg, identified by a combination of 
call identification, source and destination, a network element or UE has to compare 
the respective header fields of each SIP message and then to determine whether 
the call leg already exists. This implies heavy stjf^strjng_comparisons and data 
base queries. A network element which maintains a high number of parallel call legs 
needs a lot of resources. Additionally, in case of a failure in a network element, 
information is required about existing sessions. 

Please replace the second full paragraph on page 1 3 as follows: 
Regarding the arrangement and structure of the subfields 121 to 12n in the user 
parti 20, three options may be used. According to the first option, the user part 120 
may be arranged as a single field, which contains the subfields 121 to 12n. This 
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single field is then passed parsed and divided into the subfields 121 to 12n, when 
needed. This provides the advantage that no standardization is needed if the field is 
created and utilized inside the same network. 
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